这几年跟很多人聊过“你想解决什么问题”，得到的答案几乎都是同一种句式：“我想变好一点”“我想提效”“我想学点AI”“感觉现在这样不太对”。
我一开始会顺着往下追问：具体是哪个环节、卡了多久、理想中的状态是什么样。奇怪的是，十个人里有八个会愣住，然后说——"好像没有具体想过，就是有种应该更好的感觉"。
这不是这几个人的问题，是一个普遍现象：绝大多数人找过来的时候，手里拿的不是一个问题，而是一团情绪。“我想变好”这类表达本身没有错，但它没法被直接执行，因为它还不是一个可以被回答的问题。
"我想变好"是一句无法执行的话
一个问题能不能被解决，前提是它得先能被回答。而“我想变好”缺的恰恰是让它能被回答的东西：具体是在哪个场景卡住了，卡住的原因是能力、工具、还是流程，理想中的“好”到底长什么样。
这些信息用户自己心里其实是有一部分的，只是从来没有被人一层层问出来过。传统的解决方式要么是问卷——用户勾几个选项，系统给一份通用建议，中间的思考过程完全被跳过；要么是漫无边际的聊天——用户说什么算什么，AI顺着接话，最后聊得很热闹，但依然没有落地的方向。
这两种方式共享一个盲点：都默认用户已经把问题想清楚了，AI只需要负责给答案。但真实情况往往是反过来的——用户缺的不是答案，是一个能被回答的问题。
诊断 ≠ 建议：追问比给方案更重要
所以我做了一个「需求诊断器」，目的就是把这个被忽略的中间环节做实，网址是 start.codenow.wiki，目前内测阶段免费试用。
它不是问卷，因为选项背后跟着真人般的动态追问；也不是随便聊天，因为每一步都指向一个具体的信息缺口——场景、痛点、卡点、目标——追完这四样，模糊的感觉才第一次有了形状。
选择加补充输入的形式是刻意设计的：选择题降低表达门槛，补充输入留出真实细节的空间，AI再根据回答动态调整下一个追问——方向不是提前写死的树状逻辑，而是跟着用户的具体情况实时收窄。追到最后，用户看到的不是一份笼统的分析，而是一份诊断报告：什么问题、为什么没解决、下一步从哪开始。
这里有一个容易被忽略的设计原则：诊断本身不等于给建议。很多工具急着在第一屏就给方案，结果方案是对的，但用户看不懂自己为什么需要它——因为问题从没被讲清楚过。先把问题诊断清楚，用户自己往往就已经看到了一半的答案；剩下一半，才轮到工具或方法登场。
技术不是万能药：诚实的"不适合"比虚假的"能解决"更有价值
诊断完成之后，还有一步很多产品选择跳过的判断：这个问题到底适不适合用技术解决。
不是所有的"卡住"都该用AI编程、自动化工具去啃。有些是流程问题，换个协作方式就解决了；有些是认知问题，需要的是一次深谈而不是一个脚本；还有一些，本质上是需要真人指导的经验类问题，工具介入反而会让人错过真正该走的路。
「AI需求诊断器」在给出方向前会先做这一层判断：适合技术解决的，会被整理成具体可执行的行动方向，比如该学哪类工具、该找什么样的自动化路径；暂时不适合的，也会诚实地告诉用户——这不是产品的失败，恰恰是产品该有的克制。一个愿意说“这个可能不是技术问题”的工具，比一个逢问题就推销方案的工具，值得信任得多。
接下来会往哪走
这个诊断器目前主要在做三件具体的事：
第一，把追问逻辑沉淀成可复用的诊断路径——不同类型的卡点（效率、学习、工具搭建、职业转向）会形成各自的追问模板，追问会越来越准。
第二，诊断报告支持保存成图片，方便用户带着去找人聊，作为一次自我梳理的记录，而不是聊完就忘的一次性对话。
第三，持续观察真实用户最常卡在哪类问题上，让这个工具本身也在不断校准——它要解决的，始终是人们真正卡住的地方，而不是我以为的地方。
现在这个工具已经上线，网址是 start.codenow.wiki，欢迎带着你那句还没说清楚的“我想变好”去试一试。
回到开头那些聊过的人——他们最后说出真正卡点的时候，往往不是什么宏大的命题，而是一个具体到能在一个下午解决的小问题，只是这个问题在被追问出来之前，一直被“我想变好”这四个字盖住了。
你手里那句模糊的话，可能也只差三个问题的距离。
